Internet Surfer 2.0/Internet Surfer 2.0 (Wayzata Technology) (1996).iso/pc/text/mac/faqs.539

Text File | 1996-02-12 | 28KB | 683 lines

Frequently Asked Questions (FAQS);faqs.539



      You can then start up a program that will open your .plan file
      for writing; the open will block until some other process (namely
      fingerd) opens the .plan for reading.  Now you can whatever you
      want through this pipe, which lets you show different .plan
      information every time someone fingers you.

      Of course, this may not work at all if your system doesn't
      support named pipes or if your local fingerd insists
      on having plain .plan files.

      Your program can also take the opportunity to look at the output
      of "netstat" and spot where an incoming finger connection is
      coming from, but this won't get you the remote user.

      Getting the remote userid would require that the remote site be
      running an identity service such as RFC 931.  There are now three
      RFC 931 implementations for popular BSD machines, and several
      applications (such as the wuarchive ftpd) supporting the server.
      For more information join the rfc931-users mailing list,
      [e-mail].

      There are three caveats relating to this answer.  The first is
      that many NFS systems won't recognize the named pipe correctly.
      This means that trying to read the pipe on another machine will
      either block until it times out, or see it as a zero-length file,
      and never print it.

      The second problem is that on many systems, fingerd checks that
      the .plan file contains data (and is readable) before trying to
      read it.  This will cause remote fingers to miss your .plan file
      entirely.

      The third problem is that a system that supports named pipes
      usually has a fixed number of named pipes available on the
      system at any given time - check the kernel config file and
      FIFOCNT option.  If the number of pipes on the system exceeds the
      FIFOCNT value, the system blocks new pipes until somebody frees
      the resources.  The reason for this is that buffers are allocated
      in a non-paged memory.

4.10) Is it possible to reconnect a process to a terminal after it has
      been disconnected, e.g. after starting a program in the background
      and logging out?

      Most variants of Unix do not support "detaching" and "attaching"
      processes, as operating systems such as VMS and Multics support.
      However, there are two freely redistributable packages which can
      be used to start processes in such a way that they can be later
      reattached to a terminal.

      The first is "screen," which is described in the
      comp.sources.unix archives as "Screen, multiple windows on a CRT"
      (see the "screen-3.2" package in comp.sources.misc, volume 28.)
      This package will run on at least BSD, System V r3.2 and SCO UNIX.

      The second is "pty," which is described in the comp.sources.unix
      archives as a package to "Run a program under a pty session" (see
      "pty" in volume 23).  pty is designed for use under BSD-like
      system only.

      Neither of these packages is retroactive, i.e. you must have
      started a process under screen or pty in order to be able to
      detach and reattach it.

4.11) Is it possible to "spy" on a terminal, displaying the output
      that's appearing on it on another terminal?

      There are a few different ways you can do this, although none
      of them is perfect:

      * kibitz allows two (or more) people to interact with a shell
        (or any arbitary program).  Uses include:

    - watching or aiding another person's terminal session;
    - recording a conversation while retaining the ability to
      scroll backwards, save the conversation, or even edit it
      while in progress;
    - teaming up on games, document editing, or other cooperative
      tasks where each person has strengths and weakness that
      complement one another.

        kibitz comes as part of the expect distribution.  See question 3.9.

        kibitz requires permission from the person to be spyed upon.  To
        spy without permission requires less pleasant approaches:

      * You can write a program that grovels through Kernel structures
        and watches the output buffer for the terminal in question,
        displaying characters as they are output.  This, obviously, is
        not something that should be attempted by anyone who does not
        have experience working with the Unix kernel.  Furthermore,
        whatever method you come up with will probably be quite
        non-portable.

      * If you want to do this to a particular hard-wired terminal all
        the time (e.g. if you want operators to be able to check the
        console terminal of a machine from other machines), you can
        actually splice a monitor into the cable for the terminal.  For
        example, plug the monitor output into another machine's serial
        port, and run a program on that port that stores its input
        somewhere and then transmits it out *another* port, this one
        really going to the physical terminal.  If you do this, you have
        to make sure that any output from the terminal is transmitted
        back over the wire, although if you splice only into the
        computer->terminal wires, this isn't much of a problem.  This is
        not something that should be attempted by anyone who is not very
        familiar with terminal wiring and such.

--
Ted Timar - [e-mail]
Empress Software, 3100 Steeles Ave E, Markham, Ont., Canada L3R 8T3
Xref: bloom-picayune.mit.edu comp.unix.questions:51332 comp.unix.shell:8338 news.answers:4774
Path: bloom-picayune.mit.edu!senator-bedfellow.mit.edu!senator-bedfellow.mit.edu!usenet
From: [e-mail] (Ted M A Timar)
Newsgroups: comp.unix.questions,comp.unix.shell,news.answers
Subject: Unix - Frequently Asked Questions (5/7) [Frequent posting]
Supersedes: <unix-faq/faq/[e-mail]>
Followup-To: comp.unix.questions
Date: 24 Dec 1992 06:02:56 GMT
Organization: Empress Software
Lines: 230
Approved: [e-mail]
Distribution: world
Expires: 21 Jan 1993 06:02:09 GMT
Message-ID: <unix-faq/faq/[e-mail]>
References: <unix-faq/faq/[e-mail]>
NNTP-Posting-Host: pit-manager.mit.edu
X-Last-Updated: 1992/12/09

Archive-name: unix-faq/faq/part5
Version: $Id: part5,v 2.1 92/12/04 07:43:55 tmatimar Exp $

These seven articles contain the answers to some Frequently Asked
Questions often seen in comp.unix.questions and comp.unix.shell.
Please don't ask these questions again, they've been answered plenty
of times already - and please don't flame someone just because they may
not have read this particular posting.  Thank you.

These articles are divided approximately as follows:

      1.*) General questions.
      2.*) Relatively basic questions, likely to be asked by beginners.
      3.*) Intermediate questions.
      4.*) Advanced questions, likely to be asked by people who thought
       they already knew all of the answers.
      5.*) Questions pertaining to the various shells, and the differences.
      6.*) An overview of Unix variants.
      7.*) An comparison of configuration management systems (RCS, SCCS).

This article includes answers to:

      5.1)  Can shells be classified into categories?
      5.2)  How do I "include" one shell script from within another
            shell script?
      5.3)  Do all shells have aliases?  Is there something else that
            can be used?
      5.4)  How are shell variables assigned?
      5.5)  How can I tell if I am running an interactive shell?
      5.6)  What "dot" files do the various shells use?
      5.7)  I would like to know more about the differences between the
            various shells.  Is this information available some place?

If you're looking for the answer to, say, question 5.5, and want to skip
everything else, you can search ahead for the regular expression "^5.5)".

While these are all legitimate questions, they seem to crop up in
comp.unix.questions or comp.unix.shell on an annual basis, usually
followed by plenty of replies (only some of which are correct) and then
a period of griping about how the same questions keep coming up.  You
may also like to read the monthly article "Answers to Frequently Asked
Questions" in the newsgroup "news.announce.newusers", which will tell
you what "UNIX" stands for.

With the variety of Unix systems in the world, it's hard to guarantee
that these answers will work everywhere.  Read your local manual pages
before trying anything suggested here.  If you have suggestions or
corrections for any of these answers, please send them to to
[e-mail].

5.1)  Can shells be classified into categories?

      From: [e-mail] (Matthew Wicks)
      Date: Wed, 7 Oct 92 14:28:18 -0500

      In general there are two main class of shells.  The first class
      are those shells derived from the Bourne shell which includes sh,
      ksh, bash, and zsh.  The second class are those shells derived
      from C shell and include csh and tcsh.  In addition there is rc
      which most people consider to be in a "class by itself" although
      some people might argue that rc belongs in the Bourne shell class.

      With the classification above, using care, it is possible to
      write scripts that will work for all the shells from the Bourne
      shell category, and write other scripts that will work for all of
      the shells from the C shell category.

5.2)  How do I "include" one shell script from within another shell script?

      From: [e-mail] (Matthew Wicks)
      Date: Wed, 7 Oct 92 14:28:18 -0500

      All of the shells from the Bourne shell category (including rc)
      use the "." command.  All of the shells from the C shell category
      use "source".

5.3)  Do all shells have aliases?  Is there something else that can be used?

      From: [e-mail] (Matthew Wicks)
      Date: Wed, 7 Oct 92 14:28:18 -0500

      All of the major shells other than sh have aliases, but they
      don't all work the same way.  For example, some don't accept
      arguments.

      Although not strictly equivalent, shell functions (which exist in
      all shells from the Bourne shell category) have almost the same
      functionality of aliases.  Shell functions can do things that
      aliases can't do.

      Use unalias to remove aliases and unset to remove functions.

5.4)  How are shell variables assigned?

      From: [e-mail] (Matthew Wicks)
      Date: Wed, 7 Oct 92 14:28:18 -0500

      The shells from the C shell category use "set variable=value" for
      variables local to the shell and "setenv variable value" for
      environment variables.  To get rid of variables in these shells
      use unset and unsetenv.  The shells from the Bourne shell
      category use "variable=value" and may require an "export
      VARIABLE_NAME" to place the variable into the environment.  To
      get rid of the variables use unset.

5.5)  How can I tell if I am running an interactive shell?

      From: [e-mail] (Matthew Wicks)
      From: [e-mail] (DaviD W. Sanderson)
      Date: Fri, 23 Oct 92 11:59:19 -0600

      In the C shell category, look for the variable $prompt.

      In the Bourne shell category, you can look for the variable $PS1,
      however, it is better to check the variable $-.  If $- contains
      an 'i', the shell is interactive.  Test like so:

      case $- in
      *i*)    # do things for interactive shell
              ;;
      *)      # do things for non-interactive shell
              ;;
      esac

5.6)  What "dot" files do the various shells use?

      From: [e-mail] (Matthew Wicks)
      From: [e-mail] (Thomas M. Breuel)
      Date: Wed, 28 Oct 92 03:30:36 +0100

      Although this may not be a complete listing, this provides the
      majority of information.

      csh
      Some versions have system-wide .cshrc and .login files.  Every
      version puts them in different places.

      Start-up (in this order):
          .cshrc   - always.
          .login   - login shells.

      Upon termination:
              .logout  - login shells.

      Others:
          .history - saves the history (based on $savehist).

      tcsh
      Start-up (in this order):
          /etc/csh.cshrc - always.
          /etc/csh.login - login shells.
          .tcshrc        - always.
          .cshrc         - if no .tcshrc was present.
          .login         - login shells

      Upon termination:
              .logout        - login shells.

      Others:
          .history       - saves the history (based on $savehist).
          .cshdirs       - saves the directory stack.

      sh
      Start-up (in this order):
          /etc/profile - login shells.
          .profile     - login shells.

      Upon termination:
          any command (or script) specified using the command:
         trap "command" 0

      ksh
      Start-up (in this order):
          /etc/profile - login shells.
          .profile     - login shells.
          $ENV         - always, if it is set.

      Upon termination:
          any command (or script) specified using the command:
         trap "command" 0

      bash
      Start-up (in this order):
              /etc/profile  - login shells.
              .bash_profile - login shells.
              .profile      - login if no .bash_profile is present.
              .bashrc       - interactive non-login shells.
              $ENV          - always, if it is set.

      Upon termination:
              .bash_logout  - login shells.

      Others:
              .inputrc      - Readline initialization.

      zsh
      Start-up (in this order):
              .zshenv   - always, unless -f is specified.
              .zprofile - login shells.
              .zshrc    - interactive shells, unless -f is specified.
              .zlogin   - login shells.

      Upon termination:
              .zlogout  - login shells.

      rc
      Start-up:
              .rcrc - login shells

5.7)  I would like to know more about the differences between the
      various shells.  Is this information available some place?

      From: [e-mail] (Matthew Wicks)
      Date: Wed, 7 Oct 92 14:28:18 -0500

      A very detailed comparison of sh, csh, tcsh, ksh, bash, zsh, and
      rc is available via anon.  ftp in several places:

      cs.uwp.edu (131.210.1.4):pub/vi/shell-100.BetaA.Z
      alf.uib.no (129.177.30.3):pub/lpf/misc/shell-100.BetaA.Z
      utsun.s.u-tokyo.ac.jp (133.11.11.11):misc/vi/shell-100.BetaA.Z

      This file compares the flags, the programming syntax,
      input/output redirection, and parameters/shell environment
      variables.  It doesn't discuss what dot files are used and the
      inheritance for environment variables and functions.

--
Ted Timar - [e-mail]
Empress Software, 3100 Steeles Ave E, Markham, Ont., Canada L3R 8T3
Xref: bloom-picayune.mit.edu comp.unix.questions:51337 comp.unix.shell:8343 news.answers:4779
Path: bloom-picayune.mit.edu!senator-bedfellow.mit.edu!senator-bedfellow.mit.edu!usenet
From: [e-mail] (Ted M A Timar)
Newsgroups: comp.unix.questions,comp.unix.shell,news.answers
Subject: Unix - Frequently Asked Questions (6/7) [Frequent posting]
Supersedes: <unix-faq/faq/[e-mail]>
Followup-To: comp.unix.questions
Date: 24 Dec 1992 06:03:18 GMT
Organization: Empress Software
Lines: 698
Approved: [e-mail]
Distribution: world
Expires: 21 Jan 1993 06:02:09 GMT
Message-ID: <unix-faq/faq/[e-mail]>
References: <unix-faq/faq/[e-mail]>
NNTP-Posting-Host: pit-manager.mit.edu
X-Last-Updated: 1992/12/09

Archive-name: unix-faq/faq/part6
Version: $Id: part6,v 2.1 92/12/04 07:43:57 tmatimar Exp $

These seven articles contain the answers to some Frequently Asked
Questions often seen in comp.unix.questions and comp.unix.shell.
Please don't ask these questions again, they've been answered plenty
of times already - and please don't flame someone just because they may
not have read this particular posting.  Thank you.

These articles are divided approximately as follows:

      1.*) General questions.
      2.*) Relatively basic questions, likely to be asked by beginners.
      3.*) Intermediate questions.
      4.*) Advanced questions, likely to be asked by people who thought
       they already knew all of the answers.
      5.*) Questions pertaining to the various shells, and the differences.
      6.*) An overview of Unix variants.
      7.*) An comparison of configuration management systems (RCS, SCCS).

This article includes answers to:

      6.1)  Disclaimer and introduction.
      6.2)  A very brief look at Unix history.
      6.3)  Main Unix flavors.
      6.4)  Unix Standards.
      6.5)  Identifying your Unix flavor.
      6.6)  Brief notes on some well-known (commercial/PD) Unices.
      6.7)  Real-time Unices.
      6.8)  Unix glossary.
      6.9)  Acknowledgements.

If you're looking for the answer to, say, question 6.5, and want to skip
everything else, you can search ahead for the regular expression "^6.5)".

While these are all legitimate questions, they seem to crop up in
comp.unix.questions or comp.unix.shell on an annual basis, usually
followed by plenty of replies (only some of which are correct) and then
a period of griping about how the same questions keep coming up.  You
may also like to read the monthly article "Answers to Frequently Asked
Questions" in the newsgroup "news.announce.newusers", which will tell
you what "UNIX" stands for.

With the variety of Unix systems in the world, it's hard to guarantee
that these answers will work everywhere.  Read your local manual pages
before trying anything suggested here.  If you have suggestions or
corrections for any of these answers, please send them to to
[e-mail].

6.1)  Disclaimer and introduction.

      From: "Pierre (P.) Lewis" <[e-mail]>
      Date: Sun, 11 Oct 1992 15:29:00 +0000
      Version: 2.0

      The following is offered with no guarantee as to accuracy or
      completeness.  I have done what I can in the time available and
      it still is very much work in progress.  I hope to keep improving
      this summary.  Comments welcome:  [e-mail].  Acknowledgements
      at the end.

      First a short definition.  By Unix we mean an operating system
      typically written in C, with a hierarchical file system,
      integration of file and device I/O, whose system call interface
      includes services such as fork(), pipe(), and whose user
      interface includes tools such as cc, troff, grep, awk, and a
      choice of shell.  Note that UNIX is a registered trademark of USL
      (AT&T), but will be used here in its generic sense.

      Most Unices (the more common plural form) are derived more or
      less directly from AT&T code (some code from the first C version
      is presumably still left in most), but there are also clones
      (i.e. Unix-compatible systems with no AT&T code).

      In addition, there are also Unix-like environments (e.g. VOS)
      sitting on top of other OSs, and OSs inspired from Unix (yes,
      even DOS!).  These are not covered here.  Little on real-time
      Unices yet (although more is planned).

      Unix comes in an incredible variety of flavors.  This is to a
      large extent due to availability of sources and the ease of
      porting and modifying Unix.  Typically, a vendor of Unix will
      start with one basic flavor (see below), take ideas/code from the
      other major flavor, add and change many things, etc.  This
      results in yet another new Unix flavor.  Today, there are
      literally hundreds of Unices available, the closest thing to
      standard Unix being (by definition) System V.

      This answer was put together mostly from information on the net
      and email.  Some specific sources are also mentioned in the
      appropriate sections.

6.2)  A very brief look at Unix history.

      From: "Pierre (P.) Lewis" <[e-mail]>
      Date: Sun, 11 Oct 1992 15:29:00 +0000
      Version: 2.0

      Unix history goes back to 1969 and the famous "little-used PDP-7
      in a corner" on which Ken Thompson, Dennis Ritchie (the R in K&R)
      and others started work on what was to become Unix.  The name
      "Unix" was intended as a pun on Multics (and was written "Unics"
      at first -- UNiplexed Information and Computing System).

      For the first 10 years, Unix development was essentially confined
      to Bell Labs.  These initial versions were labeled "Version n" or
      "Nth Edition" (of the manuals), and were for DEC's PDP-11 (16
      bits) and later VAXen (32 bits).  Some significant versions
      include:

      V1 (1971):  1st Unix version, in assembler on a PDP-11/20.
     Included file system, fork(), roff, ed.  Was used as a text
     processing tool for preparation of patents.  Pipe() appeared
     first in V2!

      V4 (1973):  Rewritten in C, which is probably the most
     significant event in this OS's history: it means Unix can be
     ported to a new hardware in months, and changes are easy.  The
     C language was originally designed for the Unix operating
     system, and hence there is a strong synergy between C and Unix.

      V6 (1975):  First version of Unix widely available outside
     Bell Labs (esp.  in universities).  This was also the start of
     Unix diversity and popularity.  1.xBSD (PDP-11) was derived
     from this version.  J. Lions published "A commentary on the
     Unix Operating System" based on V6.

      V7 (1979):  For many, this is the "last true Unix", an
     "improvement over all preceding and following Unices"
     [Bourne].  It included full K&R C, uucp, Bourne shell.  V7 was
     ported to the VAX as 32V.  The V7 kernel was a mere 40
     Kbytes!

         Here (for reference) the system calls of V7:
        _exit, access, acct, alarm, brk, chdir, chmod, chown,
        chroot, close, creat, dup, dup2, exec*, exit, fork, fstat,
        ftime, getegid, geteuid, getgid, getpid, getuid, gtty,
        indir, ioctl, kill, link, lock, lseek, mknod, mount,
        mpxcall, nice, open, pause, phys, pipe, pkoff, pkon,
        profil, ptrace, read, sbrk, setgid, setuid, signal, stat,
        stime, stty, sync, tell, time, times, umask, umount,
        unlink, utime, wait, write.

      These Vn versions were developed by the Computer Research Group
      (CRG) of Bell Labs.  Another group, the Unix System Group (USG),
      was responsible for support.  A third group at Bell Labs was also
      involved in Unix development, the Programmer's WorkBench (PWB),
      to which we owe, for example, sccs, named pipes and other
      important ideas.  Both groups were merged into Unix System
      Development Lab in 1983.

      Work on Unix continued at Bell Labs in the 1980s.  The V series
      was further developed by the CRG (Stroustrup mentions V10 in the
      2nd edition of his book on C++), but we don't seem to hear much
      about this otherwise.  The company now responsible for Unix
      (System V) is called Unix System Laboratories (USL) and is
      majority-owned by AT&T.

      But much happened to Unix outside AT&T, especially at Berkeley
      (where the other major flavor comes from).  Vendors (esp. of
      workstations) also contributed much (e.g. Sun's NFS).

      The book "Life with Unix" by Don Libes and Sandy Ressler is
      fascinating reading for anyone interested in Unix, and covers a
      lot of the history, interactions, etc..  Much in the present
      section is summarized from this book.

6.3)  Main Unix flavors.

      From: "Pierre (P.) Lewis" <[e-mail]>
      Date: Sun, 11 Oct 1992 15:29:00 +0000
      Version: 2.0

      Until recently, there were basically two main flavors of Unix:
      System V (five) from AT&T, and the Berkeley Software Distribution
      (BSD).  SVR4 is essentially a merge of these two flavors.  End
      '91, OSF/1 from the Open Software Foundation was released (as a
      direct competitor to System V) and may (future will tell) change
      this picture.

      The following lists the main releases and features of System V,
      BSD and OSF/1.

      System V from AT&T.  Typical of Intel hardware.  Most often
     ported Unix, typically with BSD enhancements (csh, job
     control, termcap, curses, vi, symbolic links).  System V
     evolution is now overseen by Unix International (UI).  UI
     members include AT&T, Sun, ....
     Newsgroup: comp.unix.sysv[23]86.  Main releases:

         - System III (1982): first commercial Unix from AT&T
           - FIFOs (named pipes)  (later?)

         - System V (1983):
           - IPC package (shm, msg, sem)

         - SVR2 (1984):
           - shell functions (sh)
           - SVID (System V Interface Definition)

         - SVR3 (1986) for ? platforms:
           - STREAMS (inspired by V8), poll(), TLI (network software)
           - RFS
           - shared libs
           - SVID 2
           - demand paging (if hardware supports)

         - SVR3.2:
           - merge with Xenix (Intel 80386)
           - networking

         - SVR4 (1988), mainstream of Unix implementations, merge of
       System V, BSD, and SunOS.
           - From SVR3: sysadmin, terminal I/F, printer (from BSD?),
         RFS, STREAMS, uucp
           - From BSD: FFS, TCP/IP, sockets, select(), csh
           - From SunOS: NFS, OpenLook GUI, X11/NeWS, virtual memory
         subsystem with memory-mapped files, shared libraries
         (!= SVR3 ones?)
           - ksh
           - ANSI C
           - Internationalization (8-bit clean)
           - ABI (Application Binary Interface -- routines instead of traps)
           - POSIX, X/Open, SVID3

         - SVR4.1
           - async I/O (from SunOS?)

         - SVR4.2 (based on SVR4.1ES)
           - Veritas FS, ACLs
           - Dynamically loadable kernel modules

         - Future:
           - SVR4 MP (multiprocessor)
           - Use of Chorus microkernel?

      Berkeley Software Distribution (BSD).  Typical of VAXen, RISCs,
     many workstations.  More dynamic, research versions now than
     System V.  BSD is responsible for much of the popularity of
     Unix.  Most enhancements to Unix started here.  The group
     responsible at UCB (University of California at Berkeley) is
     the Computer System Research Group (CSRG).  They closed down
     in 1992.  Newsgroup: comp.unix.bsd.  Main releases:

         (much reorganized wrt dates and releases, hope it's converging)

         - 2.xBSD (1978) for PDP-11, still of significance? (2.11BSD
       was released in 1992!).
           - csh

         - 3BSD (1978):
           - virtual memory

         - 4.?BSD:
           - termcap, curses
           - vi

         - 4.0BSD (1980):

         - 4.1BSD (?): base of later AT&T CRG versions
           - job control
           - automatic kernel config
           - vfork()

         - 4.2BSD (1983):
           - TCP/IP, sockets, ethernet
           - UFS: long file names, symbolic links
           - new reliable signals (4.1 reliable signals now in SVR3)
           - select()

         - 4.3BSD (1986) for VAX, ?:
         - 4.3 Tahoe (1988): 4.3BSD with sources, support for Tahoe
       (32-bit supermini)
           - Fat FFS
           - New TCP algorithms
         - 4.3 Reno (1990) for VAX, Tahoe, HP 9000/300:
           - most of P1003.1
           - NFS (from Sun)
           - MFS (memory file system)
           - OSI: TP4, CLNP, ISODE's FTAM, VT and X.500;  SLIP
           - Kerberos

         - 4.4BSD (will we ever see it?) for HP 9000, Sparc, 386, DEC, Tahoe:
           - new FS organization, new process internals, new virtual
         memory based on Mach 2.5
           - POSIX compatibility
           - OSI (based on ISODE), X.25

      The Open Software Foundation (OSF) released its Unix called OSF/1
     end of 1991.  Still requires an SVR2 license.
     Compatible/compliant with SVID 2 (and 3 coming), POSIX,
     X/Open, etc..  OSF members include Apollo, Dec, HP, IBM, ....

         - OSF/1 (1991):
           - based on Mach 2.5 kernel
           - symmetric multiprocessing, parallelized kernel, threads
           - logical volumes, disk mirroring, UFS (native), S5 FS, NFS
           - enhanced security (B1 with some B2, B3; or C2), 4.3BSD admin
           - STREAMS, TLI/XTI, sockets
           - shared libs, dynamic loader (incl. kernel)
           - Motif GUI